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ABSTRACT 

Ttve  Inie|;rated  Tracking  System  (ITS)  supports  the  Mow  of  freight  to  and  ftom  die  Southern 
California  Logistics  Airport  (SCLA)  and  will  be  integrated  with  the  Inland  Porr-Multi-Modal 
Terminal  Operating  System  The  ITS  design  integrates  Contract  Line  Item  Numbers  (CLIN) 
0009  Joint  Data  Standard  and  Communications  Protocol,  CLIN  0010  the  Regional  Wireless 
Network  Design,  and  CLIN  0012  the  Regional  IT  Data  Network. 

This  project  CLIN  0009  is  to  build  a  Data  Center  to  support  all  Information  Technology 
requirements  from  the  ITS  and  evenmally  the  Joint  Deployment  and  Disinbuiion  Support 
Platform  (JDDSP).  The  design  work  includes  configuring  secure  data  capture  and  integration 
networks,  creating  the  information  tnier^cing  layer,  and  establishing  the  web  interface.  The 
algorithm  platform  is  on  the  basis  of  Web  2.0  which  is  feaiunng  Wireless,  RPID,  Ontology, 
Unifted  Modeling  Language  (UML),  Metadata,  and  XML 


VI 
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1.0  INTRODCCTION 

1.1  Backgroiiod 

The  Joint  Deployment  and  Disinbuiion  Support  Platform  (JDDSPJ  requires  an  Integrated 
Tracking  System  (ITS)  based  on  integrated  data  standards  and  standard  commimication 
protocols.  The  (TS  is  designed  to  improve  goods  movement  and  provide  effective  decision 
support  for  the  fuK  spectrum  of  military  surge  deployments,  sustainment  support  redeployments, 
and  reset  operations.  The  JDDSP  conceptual  system  architecture  will  be  composed  of  three 
layers;  (I)  a  data  capture  and  integration  layer;  (2)  a  mediation  layer;  and  (3)  an  information 
interfacing  layer  to  perform  Extraction,  Translbrmation,  and  Loading  (ETL)  processes.  The  ETL 
processes  allow  the  raw  data  to  be  convened  to  useful  information  for  both  commercial  and 
military  shipment  management. 

Accordingly,  using  data  and  data  flows  to  represent  the  physical  movement  and  key  control 
elements  in  the  shipment  tracking  system,  we  seek  to  define  the  Information  Technology  (IT) 
architecture  required  to  capture  and  enable  shipment  and  asset  tracking.  The  tracking  data 
required  by  the  JDDSP  include  commercial  and  military  Electronic  Data  Interchange  (EDI) 
segments.  Car  Location  Messages  (CLM),  Auto  EquifKiteni  Identification  (AEl)  technology. 
Radio  Frequency  Identification  (RFID)  tags,  and  sensor  readers  to  track  containers  and 
equipment  moving  to  and  through  the  JDDSP. 

The  initial  development  of  the  JDDSP-ITS  started  with  building  an  integrated  database,  currently 
named  the  SM2I  Tracking  Experimentation  Database  (STED).  Development  of  the  system 
included  configuring  secure  data  capture  and  integration  networks,  creating  the  information 
interfacing  layer,  and  establishing  the  web  interface.  Future  development  includes  testing  the 
STED  within  an  iniegraied  ITS  architecture,  which  will  support  the  JDDSP  Inland  Pon  Multi¬ 
modal  Terminal  Operating  System  (IP-MTOPS)  defined  within  the  Multi-Modal  Terminal 
Operating  Software  System  Specification  The  initial  testing  arrangement  is  depicted  in  Figure 
I  Using  this  configuration  and  leveraging  a  cooperative  agreement  with  Dole  Foods,  SM2I  will 
integrate  the  container  shipping  data  of  Dole  processed  foods  into  and  out  of  the  Southern 
California  ports  and  throughout  the  region 

1.2  Objectives 

To  develop  Joint  data  standards  and  communication  protocols  in  the  (nte^ted  Tracking  System, 
we  have  set  the  following  objectives' 

•  A  collaborative  community  of  interest  comprised  of  military  and  commercial  logistics 
planning  managers  (i.e.,  shipper  activity  planners,  rail  planners,  truck  planners, 
iniermediaie  node  planners,  marine  terminal  planners,  vessel  load  planners,  and  end 
users); 

•  An  automated  and  secure  datacenter  with  muki-tier  networks,  server  process,  domain 
name  conuciiler,  firewall  routers,  SQL/Oracle  databases,  backup/recovery  plans,  and 
various  ETL  programs; 
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•  Siraiegic  and  operaiionaj  logisdcs  data  staadards  aod  comenufucaucu]  protocol  wbiah 
can  be  used  to  track  vc&sci  inanifesL  rai)  tivaybil),  throughput  velocity,  equipment 
secuniy,  and  shipping  synehroniciiy  of  container  and  mi)iuu\  equipment  muvemeftt: 
and 

•  All  shippers  and  regiooal  Disinbution  Centers  to  have  instant  visibility  of  container 
and  equipment  shipments  which  can  enable  timely  supply  chain  distribution  and  force 
deployment  decisions  using  XML  internet  from  everywhere  in  tbe  world. 
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2.0  DATACENTER 

2.1  Site  and  Hardnore  Allocation 

TtK  miiial  aerver  atie  for  the  [TS  la  locaieil  at  the  Souctsem  California  Logiaiica  Auitwrity 
(SCLA),  Viciorvilte,  California.  The  computer  site  and  the  respective  hardware  allocation  map 
are  atvown  in  Figure  2.  As  ouilined,  the  protocols  of  TCP/IP  suite  identify  each  device  on  the 
ITS  network  by  its  Internet  Protocol  (IP)  address.  So  the  router  is  a  device  with  an  IP  address 
assigned  to  it.  The  Oaieway  router  (IP'  1 72.1 6.1 .1 )  is  the  entry  point  to  communicate  with 
eatemal  WAN  and  internet.  The  Virtual  Private  Network  (VPN)  router  (IP;  66. 162.3*.  10)  is  a 
device  to  provide  tirewall  and  security  checking.  From  here,  the  necwoiks  spin  into  two  links  lo 
connect  following  two  iniemal  networks' 

1  Local  Area  Networks  ( LAN)  of  Southern  Caliibmia  Logistics  Authority  (SCLA),  and 

2  Local  Area  Networks  of  Victorville  City  Hall. 

In  the  current  configuration,  the  SCLA  wireless  firewall  router  (IP;  172. 16  I  10)  is  the  entry 
point  to  protect  four  servers  as  tbilows; 


Table  1.  Server  Specifications 


Server 

Name 

IP  Address 

Functloatl  Supports 

llardwtre  Specifications 

SMOl 

mam 

SQL  Databa.e  Server 

Dell  Powu'ifdge  2650.  Windows 

2000  server.  Hard  disk  ISO  OBs 

SMOl 

mam 

Web  Portal  Server 

Dell  Pimu'iLdge  2050.  Windows 

2003  R2  Server.  Hard  Disk  300  GBs 

SMf)3 

172  16  1  14 

Simulation  and 

Oracle  Server 

Dell  Powu'iLdge  2950.  Windows 

2003  R2  Server.  Hard  Disk  300  GBs 

SM04 

172  16  1  15 

(ieographic 
Information  System 
Server 

Dell  Pov»i.'i£dge  2950.  Windows 

2003  R2  Server.  lUrd  Disk  1 600 

GBs 

The  four  servers  share  a  common  wide  screen  monitor  All  the  workstations  and  laptops  located 
ac  various  sues  are  able  to  use  Windows  provided  Remote  Connections  to  sign  into  these  four 
servers  and  run  specific  programs.  The  Victorville  City  I  lall  networks  are  not  in  the  scope  of 
this  project  and  will  not  be  included  in  this  report 

2  J  Technical  .Support 

The  numerous  ITS  technical  engineers  are  assigned  to  allocated  positions.  Together  all  job 
functions  will  be  able  to,  locally  or  remotely,  support  all  IT  i^uirements  at  the  Victorville 
Datacenter  Table  2  shows  a  summary  of  all  technical  supports  by  functions' 
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Tible  2.  Tcclinktl  Supports  by  Functions 


Positions 

Number  of 
Engineers 

Job  Functions 

Chief  Informaiion 
Officer 

1 

Overall  responsibilit)  in  IT  planning, 
moniiorinu  budeetino  and  Visionino. 

DaiabaM  Manager 

1 

SQL  Oracle  implcmentaiiot^,  data  modeling 
logical/physical  design,  backupi'recovery, 
coding  supports  m  data 
ev^iraci  lotv'iranslormaiiotvioadins 

Networi 

Adnunisirator 

1 

Implementation  ot  WAN,  LAN,  routers, 
TCPyJP,  Ethernet,  DNS,  and  Active 

Directory 

Server  Room 

Operator 

1 

Power  recovery,  system  reboot,  application 
job  maintenance,  and  documentation 

Web  Portal  Manager 
and  developers 

6 

SharePoini  implementation,  web  planning 
&  development,  and  web  promotion 

Application 

Develonere 

5 

Development  ol  stored  procedures  inggers, 
Matlab  nroorams  and  stow  olan  software 

(ilS  Developers 

3 

Implementation  and  development  of  ESRI 
(MS  svstem  and  sizine  on  CIS  server 

Simulation 

Developers 

4 

Implementation  and  development  of 
Rockwell  Arena 
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3.0  CONFIC  L'RATION  OF  SECD  RITY,  ROUTE  RS,  A  ND  N  ETW'ORKS 

TtK  daiacenief  security  consists  ofo  series  ofhardware  devices  and  supporting  software 
applications  and  data  communication.  TPe  devices  include  flrewalls,  routers,  a  Vimial  Private 
Network  (VPNJ,  Encryptions.  Domain  Name  Systems  (DNS),  Active  Directory  (AD),  and  SQL 
Authorization  which  will  be  described  in  die  following  sections. 

3.1  Cnoflgurotions  of  External  .Security  Rauier,  Firewall,  Mrtutl  Private  Nerwork 

As  shown  m  Figure  2,  a  Cisco  PIX  501  rouier  is  implemented  in  the  front-end  WAN  entry.  This 
exiemal  router  leaiures  first  tier  security  protection  of  Gateway  (IP:  172.1 6.1.1),  Firewalls,  and 
VPN  (IP;  66  162  3  B  10)  The  purpose  of  this  router  is  to  permit,  deny,  and  proxy  connections 
configured  by  the  overall  security  policy  set  by  Victorville  City  Hall,  SM  21,  and  Southern 
California  Logistics  Airport 

A  Gateway  is  an  entry  and  exit  point  from  the  datacenter  networks  to  external  WAN.  A  Firewall 
acts  as  a  security  guard,  standing  watch  over  data  as  ii  travels  in  and  out  of  the  Gateway.  This 
PIX  501  rouier  refers  lo  a  set  of  packet  filtering  rules  (by  pons  and  IP  addresses)  to  determine 
what  is  allowed  to  pass  as  well  as  to  keep  unauthorized  users  out  of  the  Gateway. 

The  VPN  allows  users  to  securely  connect  multiple  computers  over  the  Internet  via  IPSec,  PPTP, 
and  L2TP  tunnels.  The  SM  21  designated  users  are  authorized  to  use  a  name  and  a  password  to 
connect  to  this  VPN  (IP;  66.162.38.10).  These  Usemame/Password  and  authorization  are 
currently  managed  by  the  top  level  Security  Officer  of  the  Network  Administrator  at  Victorville 
Ciry  Hall. 

3J  (mplcnicniaiien  of  Internal  .Security  Rouier,  Firewall,  Wireless,  and  Eocrypilon 

As  shown  m  Figure  2,  another  D-Link  router  DI-B24VUP  (IP;  172  16  I  10)  is  implemented  in 
the  entry  point  of  the  datacenter's  Local  Area  Networks  (LAN).  The  purpose  of  this  router  is  to 
further  screen  out  the  incoming  messages  to  access  each  of  the  four  servers  at  the  datacenter. 

This  D-Link  device  is  a  4-Port  Wireless  Ethernet  Broadband  Router  with  Firewall,  Wireless,  and 
VPN  oapabdity.  This  router  features  the  latest  advanced  wireless  technology.  It  also  includes 
robust  Firewall  security  functions.  Filters  can  be  set  based  on  MAC  address,  IP  address,  URL, 
and  Domain  Name.  All  these  rules  can  be  completely  controlled  by  the  SM  2 1  Nerwork 
Administrator. 

The  procedures  and  speciflcaiions  to  configure  this  D-Link  router  are  outlined  as  Table  3. 
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Table  3.  Procedures  and  SpccUlcoiioos  for  I>*Liok  Router  Implrmontatlon 


Procedures 

SoecincsdOBs 

D-Link  Router  IP  Address 

h:  ihxo  1 

Username  Password 

X\XX\  YV  VYY 

VPN  Charitifl 

PPTP 

Virtujl  IP  Address 

19:  ihx:  1 

AuilicnticJiion  Prolix ol 

MSCIIVP 

VPN  Tunnel  U'senumx  Pjs.swurd 

Te-l  dimk  \/\AA 

This  D-LiAk  router  provideo  a  ^pbic  meuu  for  (he  cooG^uratiPcg  of  WAN.  LAN,  DKCP,  and 
VPN  This  IS  a  simple  yei  inieMigeiiL  web-based  setup  which  con  make  (he  router  secure  fur  use 
by  auihonud  SM  2 1  users  lo  conned  compilers  to  share  lugh-!^}eed  coaneciiuns  wKh  the  web 
poru).  simulations,  and  other  resources.  To  preveni  unwonted  Iniemei  intruder  frocn  accessing 
the  datacenier  network.^  this  router  serves  os  a  solid  Firewall  through  the  use  of  filten.  The 
major  screen  lo  set  up  the  VPN  is  shown  on  Figure  3. 


Figure  3.  Conflguratlufis  on  D*Llfik  Router  VTN 


As  well,  in  the  client  PC  wotkstauoo,  a  VPN  connection  must  be  configured  appropnaiely  lo 
connect  the  internal  rouier  1 1 92. 1 6S.0. 1 )  with  autbori?ed  Username  and  Password  The  ^operty 
security  should  be  set  as  Figure  4 
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Figure  4.  Configurations  on  Workstation  VPN 

Encryption  is  ibe  process  of  obscuring  loforouuion  (o  moke  ii  unreadable  wiiboui  special 
knowledge,  sometime*^  encryption  is  referred  lu  os  scrambling.  Encryption  can  be  used  lo  ensure 
secrecy,  bui  other  techniques  ore  siil)  needed  lo  moke  cummunicaiions  secure,  particularly  to 
verify  the  integrity  and  autheniicity  of  a  message.  Therefore,  the  workstation  VPN  propeity 
muffl  use  Microsod  CHAP  encryption  to  match  the  selection  from  the  D-Link  router  os  Figure  4. 

3  J  Cuaneciloos  of  Servers  In  LAN 

After  posstog  tbe  D-Ltok  router,  the  user  will  be  able  to  use  another  set  of  llsemame/Poisword  to 
log  into  the  servers  located  in  the  daiacenier.  All  Usemomes/Passwords  and  autbonraiioos  are 
managed  by  tbeSMZl  Network  Administrator. 
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4.0  CONFIG L'RATION  OF  OPERATING  SY  STEMS,  DOMAIN  CONTROLLER- 
ACTIVE  DIRECTORS ,  SQL  SERV  ERS,  AND  VTStAl  STUDIO 


4.1  RiToriaii  uf  VVIadoMft  Operdtlng  Sy^ieoi  and  Re|iurii(loa« 


The  piin:h-iS4;J  Windows  S42rver  hod  been  paitiuoneJ  wnb  no  more  ihon  20  gigabytes  in  ihe 
system  boot-up  drive  C:\.  A  SQL  Server  200S  and  a  Visual  Studio  200J  along  tv  ill  seed  more 
than  10  gigabytes  lo  allow  enough  room  for  ibe  fuTure  implemeolaiions  of  simulalion  soRware 
and  latemet  Infortnaiion  Services  (IIS)  As  such,  die  new  Windows  2003  server  R2  (64  bits) 
required  refonnartiog.  The  new  disks  are  assigned  97  gigabytes  lo  both  C:\  drive  and  E'\  drive, 
and  4S  gigabytes  to  ?:\  drive.  The  refuatniog  unused  52  gigabytes  are  reserved  for  future 
expansion.  The  Da  drive  is  a  default  CD^DVD  drive.  Figure  S  outlines  the  disk  managcnteni 
view  after  refortnacung. 


Ficure  5,  Disk  MaiiageiceBi  on  5fV102  Server 


4J  Crvailoo  of  Domain  Nome  .System  and  Domain  CouiroUcr 


A  domaui  controller  is  a  role  that  can  be  assigned  to  a  server  ic  a  network  of  computers  that  use 
the  Windows  hTT  level  operating  systems  The  Domain  Name  System  (DNS)  is  implemented  on 
this  Domain  Controller  server.  For  security  reasons,  die  datacenter  networks  use  the*  a  domain 
coniruller  to  manage  all  aeccsv  to  network  resourees  (servers,  dauiba.se3,  web  poitai,  printers,  and 
routers)  fur  die  SM  21  users,  groups  and  other  predetermined  external  users. 

An  Active  Directory  (AD)  is  created  on  ihe  Dmnam  Cootrolier  after  die  DNS  and  respective 
Service  are  ap^prialely  cooTigured.  The  Network  Adnunisirator  uses  ibe  AD  to  create 
Username,  Password,  Roles,  and  GraniRevoke  authorization  for  a  predetemuned  user.  The  user 
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needs  only  lo  log  in  using  (he  valid  Useenatne,  Password,  and  Donum  (o  gam  access  (o  (he 
resources,  wh»ch  are  located  on  the  datacenter  networks 

4J.  1  Dnmal  n  N  ane  System 

The  SM02  server  is  assigned  (o  be  the  Domain  Controller  for  (he  datacenter  networks.  The  DNS 
is  implemented  on  this  server  Table  4  outlines  (he  required  procedures  and  respective 
specifications  for  the  implementation 


Table  4.  Procedures  and  Specifications  for  DNS  Implementation 


Procedures 

Sotcincadoos 

WiiiJtms  ol  racitO 

Neiworkiiui  Strv  iCts 

Kcl^Ki^rkifur  kcs 

AJoiiciistrjtn  c  Tih)|s 

DKS 

( i^nfiuurjiion  Acoimi 

ii^rnjrd  LiH)kiin  Zone 

Zone  Njnio 

1  .or^ 

Zofii'  Tile 

Slrjieuit.iiK>hilits2 1  .oiv.Jns 

D\n<iiciK  ( 

Ni»  Dyiijiiiic  1,'pdaie 

DNS  IP  Address 

4JJ  DNS  Service 


After  the  DNS  is  created,  (he  DNS  Service  and  Manager  must  be  configured  The  DNS  Serv  ice 
IS  an  internet  service  that  translates  domain  namea  into  IP  addresses.  Because  domain  namea  are 
alphabetic,  they  are  easier  to  remember  than  their  counterpart  IP  addreases.  The  Internet, 
however,  is  re^ly  based  on  IP  addresses.  Every  time  you  use  a  domain  name,  a  DNS  service 
must  translate  the  name  into  the  corresponding  IP  address.  A  DNS  Manager  is  used  to  monitor 
(he  operation  of  the  DN  S  Service.  Figure  6  shows  an  overview  of  (he  DNS  M  anager  in  (he 
SM02  server. 
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Flyura  6.  DNS  Manager  In  SM02  Server 
A.3  Crvailoo  of  Active  Directory 

An  Active  Oirecior^'  (AD)  allows  a  Network  Adm^sistrator  to  assign  enterpnsc-wtde  Usemdmes, 
Passwords,  Role  auihorizafions,  10  deploy  programs  to  many  computers,  and  to  apply  critical 
updates  to  an  entire  organization.  An  AD  is  a  directory  service  used  to  store  intormation  about 
the  network  resources  across  a  domain.  An  AD  structure  is  a  bierarchical  fromework  of  objects 
The  objects  fall  into  three  broad  categories,  resources  (e.g.  printers),  services  (e.y.  e-mail),  and 
users  (e.g.  accounts,  or  users  and  groups).  An  AD  provides  information  on  the  objects,  organises 
the  objects,  controls  access,  and  sets  security. 

Each  object  represents  a  single  entity  whether  a  user,  a  computer,  a  pnnter.  an  application  or  a 
shored  data  source,  and  its  attributes.  Table  5  outlines  a)]  procedures  and  respective 
specincatiuns  for  the  AD  implementation. 


Table  S.  Prucedures  and  S|K'eincailons  for  AD  loipluiicntation 


Prveedum 

SnecllkatloiH 

Run  command 

DcC^COtOs) 

New  domain 

New  forcM 

Delauli  domain  name 

Strjk‘>’iciikubiliiv2l  local 

Database  and  lov  tilcv  njih 

C'  Hii\niniilh 

Sysvul  path 

C  vbmni  s\  s\ol 

Password  on  AD 

xxxxxxxxxxx 
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4.4  (nstaJlotion  of  SQL  Server  2005/2000  and  Msuol  .Studio  2005 

A  database  is  required  lo  support  a  centralized  datacenter  and  will  be  used  by  numerous  users  to 
read,  write,  update,  and  delete  goods  movement  information  A  Microsoft  relational  database 
system,  SQLServer  200S/2000  Standard  Editions,  are  implemented  in  the  SU02/SM01  servers. 
This  SQL  Server  includes  following  components' 

•  Server  database  engine 

•  Analysis  services 

•  Reporting  services 

•  Integration  services 

•  Documentation  and  samples 

A  SQL  Server  2005  Client  Component  is  also  implemented  in  numerous  remote  workstations. 
All  designated  users  are  able  to  connect  to  the  SM02/SM01  SQL  Servers  using  the  SQL  client  in 
the  workstations 

Another  coding  editor  is  required  to  help  user  programming  process  A  new  Visual  Studio  2005 
kS  implemented  and  bundled  with  SQL  Server  2005  in  the  SM02  server.  Tins  Visual  Studio 
provides  numerous  editing  functions  to  support  the  SM  21  project  programming  requirements  in 
the  following  Languages: 

•  Transact  SQL,  Stored  Procedures,  Triggers  (For  SQL  database  loading! 

•  03  (For  SQL  data  U'ansformauon! 

•  Visual  Basic  (For  SQL  data  processing) 

•  HTML,  XM  L.  XS  L  I  For  web  database  query) 

•  ASP,  JavaScript,  VBScnpi  (For  web  mam  menu) 
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5.0  OBJECT-ORIENTED  UNIFIED  MODELING  LANGUAGE 

TtK  Objeci-Orieniad  Unified  Modeling  Language  {UML)  models  completed  in  this  section  will 
be  used  by  the  Objeci-Onemeil  doiabose  design  and  Metadata  expon  in  Sections  6  and  7. 

5.1  Background,  Purpose,  and  Definitions 

5.1.1  OI>Ject*Orlcoted 

Tradiiionally,  a  program  has  been  viewed  as  a  logical  procedure  that  takes  input  data,  processing 
It,  and  producing  output  data.  The  programming  challenge  was  seen  as  bow  to  write  the  logic, 
not  bow  to  define  the  data  Tbis  metbc^  is  still  appropnate  for  use  by  a  majority  of  applicadons 
developed  today. 

Objeci-Onented  (00)  database  design  and  programming  are  new  development  practice 
organized  around  ‘objects’  raiber  than  ‘actions'  and  around  'data’  rather  than  ‘logic'.  The 
purpose  of  Object-Oriented  database  design  and  programming  is  to  take  the  view  that  what  we 
are  interested  in  the  objects  to  manipulate  rather  tban  the  logic  required  to  manipulate  them 

An  (X>  model  of  a  database  contains  class,  object,  property,  method,  and  association.  Their 
major  roles  are  to  describe  the  data  representation  and  object  nature  of  relationships  among 
entities.  Table  6  illustrates  DO  surrogates  and  examples  to  be  used  by  the  Integrated  Tracking 
System. 


Table  6.  Illusiratlon  of  Surrogates  Using  Wireless  Data  Collectloos 


SURROGATES 

DEFINITIONS 

EXAMPLES 

Class 

A  certain  related  application 
entities,  processing  methods, 
and  properties  grouped 
coeether  to  renreseni  a  class. 

Wireless  lags,  sites  plus  underneath 
programs,  properties,  associations, 
messages,  and  variables. 

Instance 

One  instance  date  of  a  class 
representing  one  application 
data  unit  in  a  class 

One  container 

Object 

One  physical  representation 
in  a  class. 

One  container  tag  or  a  site  location. 

Property 

A  characteristic  that 
describes  an  entity  or  an 
anribute. 

All  the  data  types  and  respective  sizes 
of  each  object  attribute  in  the  central 
database. 

Method 

A  lunccion  or  a  program  that 
provides  process  for  the 
class. 

All  subroutines,  funciions,  stored 
procedures  written  to  perform 
extraction,  iransfbrmaiion,  and 
loading  10  generate  a  central  database 
for  demonstration 

Association 

A  relationship  that  connect 
two  entities  or  classes. 

All  foreign  keys  built  in  the  central 
database. 
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5.1  J  L'olf)«d  Modeling  Looguage 

TtK  first  step  in  DO  is  to  identify  all  the  objects  you  want  to  mnnipulnie  and  how  they  relate  to 
each  other,  which  is  often  referred  to  as  data  modelmg  In  this  Integration  Tracking  System,  the 
UML  wilt  be  used  to  analyze  and  design  the  models  of  object  interface,  class,  activity,  and 
deployment. 

The  UML  is  a  standard  modeling  tool  for  specifying,  visualizing,  constructing,  and  documenting 
the  artifacts  of  engineering  systems,  business  systems,  and  other  non-sotlware  systems.  The 
UML  represents  a  collection  of  best  technical  practices  that  have  proven  successful  in  the 
modeling  of  large  and  complex  systems.  The  UML  is  also  a  major  tool  for  developing  an 
Object-Oriented  system  and  its  software  development  process  The  UML  uses  mostly  graphical 
notations  to  express  the  design  of  software  projects. 

The  purposes  of  the  UML  used  in  this  ITS  are  to: 

1  Provide  team  members  (of  simulations,  networks,  wireless  tracking,  supply  chains) 
with  a  ready-to-use,  expressive  visual  modeling  language  so  they  can  develop  and 
exchange  meaningful  models, 

2  Provide  extensibility  and  specialization  mechanisms  to  extend  the  core  wireless 
tracking  concepts, 

3  Be  independent  of  particular  programming  languages  (Stored  Procedures,  XML,  and 
C#)  and  development  processes, 

4  Support  higher-level  development  concepts  such  as  collaborations,  ftameworks, 
patterns,  and  components,  and 

5  Integrate  best  practices  for  future  system  developments. 

5.2  Ohjectcd'OrIcoted  UML  Analysts  and  Destgii 

The  UML  diagrams  are  designed  to  let  developers  and  stakeholders  view  an  application  system 
from  diftereni  perspectives  and  in  varying  degrees  of  abstraction.  Four  UML  diagrams  which 
are  commonly  created  in  visual  modeling  tools  are  outlined  in  the  following  sections. 

5.2.1  Use  Case  Diagram 

A  use  case  is  a  set  of  scenarios  that  describe  an  inieracuon  between  a  user  and  a  system  to 
complete  a  task.  A  use  case  diagram  displays  the  relationship  among  actors  and  use  cases. 

An  Actor  is  the  representation  of  a  person  or  system  which  exists  outside  the  system  under  study 
and  who  (or  which)  performs  a  sei^uence  of  aedviues  in  a  dialogue  with  the  system.  A  Use  Case 
represents  a  single  interaction  between  a  primary  actor  (who  inmates  the  interaction)  and  other 
(secondary)  actors,  and  the  system  itself  The  interaction  is  presented  as  a  sei^uence  of  simple 
steps 
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Uae  case  de\ebpreent  siiuis  by  lisiiag  a  sei^ueace  of  steps  that  a  ^preent  and  a  siakaholder 
mtyhi  fake  in  order  lo  compleie  an  action.  In  die  case  ofa  container  shipmenL  We  tbilowing 
step)  might  apply; 

I  Scan  a  container  la^  tn  a  remoie  site. 

2.  Push  records  to  central  database  ser^'er. 

3  Eviraci,  iransrorm,  and  load  records  isto  a  database. 

Then  a  user  stakeholder  will  contisue  with  the  toilowing  steps' 

1  Select  a  truck  route  or  a  train  route  to  browse  container  iafennDtioo. 

2  Execute  a  stored  procedure  to  select  required  records 

3  Generate  XML  and  XSL  document  listing. 

4  Display  container  uUbrmation  on  a  wefc. 

These  steps  are  represented  in  the  fuDowing  Use  Ca.se  Diagram  (Figure  7). 


Figure  7.  Use  Case  Dlagrudi 
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5JJ  Class  Dltgrom 

A  class  diagram  is  widely  used  to  describe  the  Types  of  objects  in  an  00  system  and  ibetr 
relationships  and  behavior  (process).  A  class  diagram  contigurea  class  structure  and  behavKir 
using  design  elements  such  as  classes,  objects,  associaiions,  and  methods.  Basically,  a  class 
diagram  describes  three  different  perspectives  of; 

1  Conceptual, 

2  Specification,  and 

3  Implementation 

These  perspectives  can  be  transformed  into  five  elements  in  a  class' 

1  Objects 

2  Instances 

3  Properties 

4  Associaiions 

5  Methods 

These  elements  become  evident  as  the  diagram  is  created  and  help  solidify  The  design  A  class 
diagram  can  display  an  association  (relationship)  such  as  containment,  mheriiance,  and 
association.  An  association  shows  the  relaiionship  between  instances  of  classes  The 
multiplicity  of  the  association  denotes  the  numbee  of  objects  that  can  participate  in  their 
relationship  (1  to  I,  I  to  N).  The  Integration  Tracking  System  can  be  configured  by  using  these 
elements  to  generate  a  Class  Diagram  as  Figure  6 
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Figure  8.  Clasfei  Diiyram 


5,2.3  Aclivir)  Diagram 

An  ociivicy  diagram  describes  ihe  worttflow  behavior  of  a  sysiem.  Ii  can  thuw  aciiviiies  that  are 
candiiiondl  or  parallel  An  activity  diagram  i»  al»  usetul  for  (I  j  AnoJy^ing  a  use  case  by 
desenbug  whai  aciioos  must  lake  place  and  when  they  should  occur;  (2)  Describtog  a 
complicated  sequeoiial  algonibm;  and  (3)  Modeling  applications  with  parallel  processes. 

Activity  diagrams  are  read  from  top  lo  bottom  and  use  tranches  and  forks  to  desenbe  condiuons 
and  parallel  activities.  A  fork  is  used  wlien  nuilttple  activities  are  occurrmg  at  the  same  time. 
Figure  9sbows  bow  the  activities  ofa  wbeless  tag  record  are  colJecied  and  where  they  are 
transferred 
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5J.4  Physktl  •Componcot  Dlogram  and  Deployioeoi  Dltgrom 

Ttverc  are  two  types  of  physical  dtagrams'  deployment  and  component.  A  deployment  diagram 
shows  the  physical  relationship  between  hardware  and  software  in  a  system.  A  component 
diagram  shows  the  software  components  of  a  system  and  bow  they  are  related  to  each  other. 

Many  times  the  deployment  and  component  diagrams  are  combined  into  one  physical  diagram 
A  combined  deployment  and  component  diagram  consolidates  the  features  (hardware  and 
software)  of  both  diagrams  into  one  diagram. 

The  deployment  diagram  contains  nodes  and  connections.  A  node  usually  represents  a  piece  of 
hardware  such  as  a  server  or  a  router  in  the  ITS  A  connection  depicts  the  communication  path 
used  by  the  hardware  lo  communicate  and  usually  indicates  a  method  such  as  TCP/IP  and 
Eihemei. 

The  component  diagram  contains  components  and  dependencies.  Components  represent  the 
physical  packaging  of  a  module  of  codes  (stored  procedures  or  functions).  The  dependencies 
between  the  components  show  how  changes  made  to  one  component  may  affect  the  other 
components  in  the  system.  Dependencies  in  a  component  diagram  are  represented  by  a  dashed 
line  between  two  or  more  components. 

Figure  10  below  shows  the  combined  deployment  and  component  diagrams  providing  a  high 
level  physical  description  of  the  completed  system.  In  the  Datacenter,  there  are  four  servers  of 
SMOl .  SM02,  SM03,  and  SM04.  Each  server  has  been  loaded  with  critical  application  software 
and  databases.  Figure  10  provides  the  reader  with  a  quick  overall  view  of  the  enure  system. 

Al  I  four  U  ML  models  will  be  used  as  a  basi  s  to  develop  GO  da(aba.<;es  and  programs  in  the  next 
seciions. 
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Figure  10.  Cudiblaed  Ditgramt  of  Cunipooeoi  and  Deploymvni 
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6.0  INTEtJRATION  OF  DATABA.SES  AND  DATACENTER 

The  Lisk.*  uf  Objeci-Orienied  jQUbaie  dest^n  eompleied  in  Uils  Keciion  were  used  for  ihe 
MeudQU  creaiion  found  in  Section  7. 

6.1  Duiu  Collection  and  Trtiisfcr  Systcjn  for  Radio  Frequency  Ideniincailoii 

A  data  coUeciion  and  iransfer  sysiero  providc'd  by  RPID  ia  proposed  for  ibia  project  This  system 
includes  both  liie  sensor  controller  hardware  and  soitware  (remote  sites),  and  Dalacentcr 
hardware  and  software.  One  remote  site  may  support  several  locations  (i.e.  East  Gale  and  West 
Gate)  where  the  sensors  are  implemented  separately.  All  ibe  site  controllers  share  a  common  set 
of  software  that  is  unique)  y  configured  tor  each  sire.  The  site  controller  is  responsible  for 
collecting  data  Irom  each  location,  as  well  as  inierracisg  with  sensor  hardware,  buffering  sensor 
hardware  status  and  RFID  read  events,  and  report ng  to  the  Datacenter  (via  a  secure  Internet 
connection).  Tbe  Datacenter  receives  repons  from  all  of  the  site  controllers  in  near  real-time 
basis  The  repoiteJ  status  and  events  are  processed  and  stored  in  the  JDDSP  database  The 
XML  Web  applicatiOD  system  provides  near  real-time  access  to  this  mibrmalion  for  auihimzed 
users  on  the  (aiemet  via  a  secure  VPN  website  (hTtp:/'SM02/Regional_Planning/Defauliaspx) 
The  JDDSP  database  also  receives  and  distributes  event  reports  from  other  sources  such  as  the 
seaports  and  weigh  stations  via  their  respective  mformaiion  management  systems  (IMS)  The 
data  coUectioo  and  transfer  are  displayed  in  Figure  11. 
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Figure  II.  Data  Colicciloo  and  Transfer  System  of  RFID 
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This  dau  collection  and  transfer  system  consists  of 

•  Data  Acquisition  (by  Sensors) 

•  Data  Collection  (by  Workstations) 

•  Data  Transfer  (by  intemeis) 

•  Data  Loading  (by  SQL  process) 

•  Data  Demonstration  (by  XML  Webs) 

This  software  is  developed  in  a  flexible  baseline  collection  system  which  can  be  easily  adapted 
to  ocher  similar  devices,  i.e.  CLM,  AE),  Savi  RRD  technology,  eSealing,  etc.  (f  necessary  (for 
security  or  other  reasons),  the  software  can  be  cloned  and  modified  to  support  other  railways, 
warehouses,  gate  operation,  or  u^e  lanes  at  remote  physical  locations.  This  data  collection  and 
transfer  system  is  not  limited  to  commercial  vehicle  trucks,  but  also  handles  marine  and  rail 
transportation  equipment  The  software  architecture  of  the  datacenter  and  the  remote  Site 
Controller  allows  rapid  revision  and  integration  to  support  other  device  drivers,  new  sensors,  and 
communication  protocols  as  they  become  necessary. 

Several  data  collection  and  record  reformats  are  conveyed  in  the  following  sections 
6J  Trade  Corridor  Operating  System 

The  Trade  Corridor  Operating  System  (TCOS)  is  a  system  of  hardware  and  software  that  was 
developed  by  TransCore  Corporation  originally  for  the  Washington  State  Department  of 
Transportation  (WSDOT)  to  implement  the  Northwest  Iniemaiional  Trade  Corridor  and  Border 
Crossing  System  (NWITC)  The  ports  of  Seattle  (American  President  Lines  ( APL))  and  Tacoma 
(Maersk  Sealand)  are  integrated  into  the  system  along  with  the  Washington  State  Commercial 
Vehicle  Information  Systems  and  Networks  (CVISN)  weigh  stations  and  commercial  vehicle 
database. 

These  sites  are  ouifined  with  roadside  Automatic  Vehicle  Identification  (AVI)  sensors  (to  read 
CVISN  Radio  Frequency  Identification  vehicle  tags)  and  other  wireless  sensors  for  reading 
electronic  container  seals  (e-seals)  and  Free  and  Secure  Trade  (FAST)  compatible  vehicle  sucker 
tags  and  dnver/crew  ID  cards 

As  a  part  of  ITS,  TCOS  will  capture  sensor  and  other  tracking  data  As  an  example,  TCOS  will 
be  used  to  pass  e-seal  tracking  data  to  the  JDDSP  database.  When  a  container  sealed  with  an  e- 
seal  tag  passes  a  gate  sensor  site  the  tag  will  be  read  and  the  record  will  be  logged  into  the  site 
workstation  (a  PC).  Every  1 5  minutes,  a  file  with  all  scanned  records  will  be  sent  (PUSI  led)  lo 
the  JPPSP  (SCLA)  datacenter  A  sample  scanned  record  layout  is  provided  in  Table  7.  This  file 
in  text  format  contains  certain  required  data  from  a  site  scan  reader. 

Table  7.  TCOS  Event  Record  Layout 


Field  Name 

Data  TvT>e 

Leoeth 

JllOCl 

Varctiji 

Dlfcwtjon 

Nvifilur 

20 
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Lane 


Time 


le 


Route 


Latiiude 


VehType 


Veh 


Carrier 


TagSianji 


TagData 


Sticker 


ScickerStaius 


VehGPS 


VehGPSStarus 


Crew 


CrewStaius 


Container 


ContaineiChJc 


ContainerTa 


ConiainerStacus 


ConiaineKiPS 


ConiaineKiPSStatus 


ContamerDegreeC 


Inbound 


Chassis 


ChaasisTag 


ChassisSiatiiS 


Seals 


eSeal 


eSealDaia 


eSealScarus 


Tamperaiure 


Unii 


Sensors 


SensorSiams 


SensorCounis 


SensorSyncMms 


Reefer 


Varchar 


Daietcme 


Varchar 


Varchar 


Varchar 


Numenc 


Numenc 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Varchar 


Ini 


Varchar 


32 


5.2 


5.2 


20 


32 


32 


24 


20 


20 


20 


4000 


16 


20 


24 


20 


lOO 


100 


12 


2 


24 


20 


24 


20 


100 


24 


17 


24 


24 


20 


lOO 


24 


4000 


100 
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ReeterStarus 

Varchar 

24 

ReeterDep^reeC 

Varchar 

lOD 

CreneratorSet 

Varchar 

24 

GeneratorSetSiatus 

Varchar 

24 

CieneraiorSetFuel 

Numeric 

5.2 

Cariio 

Varchar 

100 

Can?  oS  cams 

Varchar 

IOC 

Inspector 

Varchar 

24 

OrossLbs 

Numeric 

10.2 

IlazMaienal 

Varchar 

1 

OtTRoute 

Varchar 

1 

Timeout 

Varchar 

1 

Evaluation 

Varchar 

24 

EvaluationStatus 

Varchar 

20 

VehClass 

Int 

4 

VehOrossLbs 

Numeric 

S.2 

VehLcnpth 

Numeric 

5.2 

Vehilieght 

Numeric 

5.2 

Veh  Width 

Numeric 

5.2 

VehSiseed 

Numeric 

5.2 

VehAxles 

Numeric 

5.2 

AxleSpeed 

Varchar 

100 

Axle  Lbs 

Varchar 

100 

LetlAxleLbs 

Varchar 

100 

6J  Car  Location  Measaces 

TtK  mfonnation  gatJ^ered  by  railcar  AE(  lag  readers  can  be  used  by  railroad  irafTic  managers  or 
cusiomef  service  departments  to  locate  a  shipment  for  a  customer  at  almost  any  point  along  iis 
route.  It  also  helps  out  in  waybill  generation  by  eliminating  the  information  entry  errors 
normally  associated  with  manual  reporting.  These  CLM  message  data  sets  are  useful  when 
tracking  a  tram  through  certain  areas  to  monitor  train  movement  progress  and  determine  delays 
and  impediments  to  the  train  transit. 

CLM  are  generated  after  a  tram  passes  an  AEl  tag  reader  site.  CLM  contain  predetermined 
railcar  location  data  like  inventories  of  yards  and  tram  consists  The  message  records  are 
generated  by  passive  electronic  tags  afExed  to  railcars,  one  on  each  side  of  the  railcar,  passing 
electronic  reader  antennae  located  at  specific  points  in  the  rail  system  The  collection  of  this 
information  is  cmical  for  the  management  of  an  etlicient  rail  schedule  and  for  the  asset 
management. 

The  CLM  provides  electronic  conneciiviry  ansong  suppliers,  shippers,  and  earners  with  the 
exchange  of  vital  transportation  data  sets,  (i  serves  as  a  single  source  of  data  collection  from  all 
reporting  railroads  to  update  rail  shipments.  CLMs  are  available  from  ail  Class  I  earners  and 
over  250  Shonline  railroads. 
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An  axotnple  of  a  CLM  message  record  (ayoui  provided  by  Military  Surface  Deployment  and 
Distribution  Command  (SDDCJ  is  provided  m  Table 

Table  8.  CLM  Record  Layoui 


Record  Posttlous 

Field  Names 

1 

Equip  Initial 

S 

EouiD  No 

ll 

PONi* 

DOL 

83 

ShmDate  MMDDYYYYHHMl 

95 

Route 

130 

Origin  City 

160 

OriL'in  stdtc  Prov 

162 

Destination  Citv 

192 

Destination  State  Pro* 

194 

Shipper 

254 

C'otlSlkTtK’C 

314 

Original  Estimate  Time  Arrived'  MMDDYYYYHHMl 

326 

D>fiainic  Estimate  Time  Arrived  MMDDYYYYHHMl 

338 

AAR  Code 

339 

C'LM  C\>de 

.'48 

CLM  Cirv 

357 

CLM  State 

359 

CLM  Destination 

368 

CLM  Datetime.  MMDDYYYYHHMl 

380 

Report  Railroad 

384 

Note 

6.4  Automatic  Equipment  Idcniincoilon  Data  Collection 

In  ibe  early  1990s  something  new  came  along  that  allowed  railroads  lo  retire  their  pencils  and 
automate  the  way  they  keep  tabs  on  a  rolling  stock  li  is  called  Automatic  Equipment 
Idenufbcaiion.  AEl  files  are  text  files  m  a  formal  designated  by  the  Association  of  American 
Railroads  (AAR).  They  contain  key  data  elements  such  as  the  Railcar  Number,  the  length  of 
tram  and  speed  and  direction  at  time  of  passing  an  AE)  reader  site,  as  well  as  the  date  and  time  ot 
passing  the  reader  site.  The  files  are  sent  afier  passing  a  reader  sue  via  dialup  service  to  the 
railroad  which  uses  them  to  verity  shipments  and  assets. 

AEl  messages  provide  information  about  railcars  passing  a  certain  point  in  the  railcar  (racking 
system  of  the  railroad.  The  AE)  tags  have  two  record  formats:  the  T94  Header  and  T94  Detail 
The  T94  Header  format  is  shown  in  Table  9. 
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Tahk  9.  T94  I  leader  Lt>  out 


Record  Positions 


Field  Names 


Site  ID 


Event  Sian  date 


Even!  Sian  lime 


Ev  cni  Sion  time 


Time  zone 


Daylifihi  savincs  indicaior 


Data  formal  version 


Seojence 


Conversion  status  (locomotives) 


Conversion  status  (cars) 


Direction  of  travel 


Switch  direction 


Unit  of  measure 


Max  tram 


Mm  tram  speed 


Averace  train  speed 


Tram  movement 


Termination  status 


Transmission  type 


Adiacent  irack  oi.cunicd 


Train  Icnjtlh 


Ei^uipmeni  status 


Total  locomotives 


Tajuted  locomotives 


Total  cs^uipmcnl 


Tdured  cquinmcnt 


Total  axles 


The  T94  Deiail  formal  is  shown  in  Table  10: 


Table  10.  T94  Dcioll  Lavouf 


Record  Positions 


Field  Names 


Sequence  number 


C<iC'  number 


Euuiniiicnl  iiiilial 


Eoumiiictii  number 


Dricnijtion 


Reserved 


Axle  conversion  code 


Tau  deiail  .status 
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^7 

Hand  shakes  antenna  0 

29 

Hand  shakes  antenna  1 

31 

Sneed 

34 

Alik  count 

36 

Platform  count 

63  Electronic  Dait  lotercbtnge 

Since  1983,  the  iransponaiion  industry  in  US  has  been  using  the  Aniencan  National  Standards 
Institute  (ANSI)  accredited  Standards  Committee  XI2  Electronic  Data  Interchange  (EDI)  formal 
(Muller,  1999),  even  though  US  rail  and  motor  earners  EDI  usage  were  non-compatible.  The 
purpose  of  EDI  data  transmission  is  to  allow  transaction  sets  ofdifTereni  types  to  be  transmuted 
bom  one  party  to  another  in  the  same  structure.  This  hierarchical  structure  of  headers  and 
trailers  allows  the  data  to  be  segregated  logically  for  easy  interpretation  by  a  receiver  m  the  same 
industry.  For  the  requirements  to  build  the  JDDSP  database,  we  highlight  the  following  data  sets 
which  are  requested  and  collected  in  the  related  areas  of  ocean,  highway,  and  rail  shipments' 

2^  Motor  Carrhr  Load  TMtdor 

This  transaction  set  can  be  used  to  allow  shippers  or  other  interested  parties  to  offer  (tender)  a 
shipment  to  a  full  load  (truckload)  motor  earner  including  detailed  scheduling,  equipment 
requirements,  commodities,  and  shipping  instructions  pertinent  to  a  load  tender.  It  is  not  to  be 
us^  to  provide  a  motor  earner  with  data  relative  to  a  Less-than-Truckload  bill  of  lading,  pick-up 
notification,  or  manifest. 

214  Traa^nailoa  Carrhr  Shipioout  Statoa  Messago 

This  transaction  set  can  be  used  by  a  transpoitation  earner  to  provide  shippers,  consignees  and 
their  agents  with  the  status  of  shipments  in  terms  of  dates,  times,  locations,  route,  identifying 
numbers,  and  conveyance. 

J04Sbipplag  tasiroctfoas 

When  this  transaction  set  is  transmitted  to  an  ocean  carrier,  it  provides  all  the  information 
necessary  to  prepare  and  distribute  a  contract  of  carnage  such  as  an  ocean  bill  of  lading,  sea 
waybill,  and  other  shipping  documents.  When  this  transaction  set  is  transmitted  to  a  freight 
forwarder  or  customs  broker,  it  provides  for  the  transmission  of  shipping  and  financial 
information  required  by  the  forwarder  or  customs  briber  to  move  cargo  and  provide  the  services 
requested 

M9  Customs  Manifest 

This  transaction  set  can  be  used  by  earners,  terminal  operators,  port  authoniies,  or  service 
centers  to  provide  Customs  with  manifest  data  on  cargo  amving  in  or  departing  from  oceangoing 
vessels,  railroad  trams,  or  other  types  of  conveyances  This  transaction  set  can  be  also  used  by 
earners  to  provide  terminal  operators,  port  authoniies,  or  service  centers  with  manifest  data  on 
cargo  amving  at  their  facilities  via  the  conveyances  mentioned  above. 
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JISSwus  Dctalh  (Octaaf 

This  iran^iion  sei  can  be  used  to  provide  e)l  the  intbrmation  necessary  lo  report  stacus  or  event 
details  for  selected  shipments  or  containers.  It  is  intended  to  accommodate  the  details  for  one 
sums  or  event  associated  with  many  shipments  or  containers,  as  well  as  more  than  one  status  or 
event  for  one  shipment  or  conuiner 

322  Termlaal  Optrathtta  aad  lattrmodal  Raaip  A  cthii} 

This  transaction  set  can  be  used  to  provide  all  the  intbrmaiion  necessary  for  a  terminal  operation, 
port  authority  or  mtermodal  ramp  to  communicate  terminal  and  intermodal  ramp  activities  (e.g . 
"mgates*'  and  "outgates"!  to  authorized  parties  to  a  shipment. 

444  RaU  Cartier  Sblpmeai  luformalloa 

This  transaction  set  can  be  used  to  transmit  rail-carner-specific  bill  of  lading  information  to  a 
railroad,  (t  is  the  initial  tender  of  a  shipment  between  a  consignor  and  a  rail  earner  and  can  be 
used  as  notification  of  equipment  release  and/or  a  legal  bill  of  lading. 

4l8RallAd\auce  imerebaage  Consist 

This  transaction  set  can  be  used  to  transmit  advance  information  on  equipment  being 
interchanged  to  a  connection  rail  earner,  from  a  consignor  or  to  a  consignee 

856  Ship  Soricr/.Maaifest  (Ceaeraih  astd  for  cooioicrclal  Shipmcnis) 

This  transaction  set  can  be  used  to  list  the  contents  of  a  shipment  of  goods  as  well  as  additional 
information  relating  to  the  shipment,  such  as  order  information,  product  description,  physical 
characieristics,  type  of  packaging,  marking,  carrier  information,  and  configuration  of  goods 
within  the  U'ansportation  equipment.  The  transaction  set  enables  the  sender  to  describe  the 
contents  and  configuration  of  a  shipment  in  various  levels  of  detail  and  provides  an  ordered 
flevibility  to  convey  information.  The  sender  of  this  u^saciion  is  the  organization  responsible 
for  detailing  and  communicating  the  contents  of  a  shipment,  or  shipments,  to  one  or  more 
receivers  of  the  transaction  set  The  receiver  of  this  transaction  set  can  be  any  organization 
having  an  interest  in  the  contents  of  a  shipment  or  information  about  the  contents  of  a  shipment 

l^sbipoicot  Informatha  (Mainly  used  for  Go  \  rr ament  Shipatents) 

This  U'ansaciion  set  can  be  used  to  provide  the  sender  with  the  capability  to  transmit  detailed  bill- 
of-lading,  rating,  and'or  scheduling  information  pertinent  to  a  shipment.  This  transaction  set  can 
also  be  used  to  exchange  Government  Bills  of  Lading  (GBLs),  Commercial  Bills  of  Lading 
(CBLsK  Transportation  Control  and  Movement  Documents  (TCMDs),  and  Personal  Property 
(iovemmeni  Bills  of  Lading  (PPOBLa).  It  may  be  used  by  the  U.S.  Civilian  Government,  U.S 
Department  of  Defense,  and  any  of  their  trading  partners  to  exchange  information  about  the 
shipment  of  freight,  household  goods,  and  passengers.  This  transaction  sei  fulfills  information 
requirements  established  by  U.S.  Government  transportaiion  movement  rules  and  regulations. 

6.6  t'MLCR  and  Suppotilng  Data 

In  order  to  provide  certain  functions  m  the  database,  specific  supporting  data  are  required  A 
Universal  Machine  Language  Equipment  Register  (UMLER)  is  a  data  file  that  has  all  freight 
equipment  characienstics  and  speaticaiions  recorded  for  proper  use  of  rail  industry  equipment. 
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TtKse  data  r^ords  are  mainiameil  by  tlve  Business  Services  Division  (nierline  Service  of  ibe 
Association  of  American  Railroads,  RAIUNC.  These  data  are  coniamed  in  the  UMLER  tile. 
Specific  evcerpis  from  this  very  large  UMLER  file  are  normally  used  m  the  calculation  of  a  train 
consist  in  our  database  ETL  process  We  also  use  this  tile  to  extract  length,  width,  height,  and 
weight  of  a  container  in  this  project.  A  sample  tile  was  provided  free  ot'charge  here.  This  file  in 
text  format  (Table  1 1 )  contains  certain  required  data  for  all  intermodal  equipment  in  North 
Amenca. 


Table  11.  UMLER  FUe  Lavoui 


Field  Name 

Position 

fwmm 

Descrioilon 

Marl 

14 

4 

Alpha  mark  ot  car 

Number 

5  10 

ft 

ot  c^t 

ArtiCul.iiod<  <»uni 

III: 

> 

Number  td  ntdtloriiis  iii  set 

ArtiCul.iIod<  tale 

n  14 

> 

Articulated  onl\ 

ISIS 

4 

Foi  drlieulaiod  tsne  i<  one  oosiiion 

GutSide  Lenuth 

19-:? 

5 

Base  oiiK 

Platform  Li'imtti 

4 

Platfon  11  Width 

:s.?i 

4 

lidsc  onK 

Bulkin' ad  lloik'lii 

?:.?5 

4 

Tare  Wfiuht 

4 

Load  Liiiiii 

40-43 

4 

44  45 

> 

Aniculdtcd  onK 

Container  C'jndcii\  <  tnle 

4A.4' 

> 

Articulated  onl\ 

Axles 

4S.49 

> 

Ba>e*tml> 

6.7  OhJeci'OrIcoied  Database  Design 

The  integration  of  required  RFID,  CLM,  AEI,  and  EDI  data  into  an  GO  database  is  necessary  for 
successful  shipment  and  transportation  asset  tracking  and  management.  The  purposes  of  the 
JDDSP  database  design  are  loi 

•  Automate  the  ETL  process  and  store  the  data  without  unnecessary  redundancy. 

•  Allow  users  to  query  information  in  a  net  centric  environment. 

•  Provide  tracking  services  within  a  Service  Oriented  Architecture 

•  Secure  all  data  to  meet  predetermined  military  and  commercial  policies 

•  Configure  the  databases  and  the  programs  using  objects  and  classes. 

Therefore,  a  key  step  to  the  GO  design  is  to  establish  relationships  among  objects.  We  define  an 
entity  as  an  object  about  which  we  store  data,  e.g.,  physical  thing,  person,  place,  event;  establish 
relationships  between  entities,  i.e.,  l-io-l,  l-to-many,  many-to-l;  and  form  relational  data  model 
structure  in  only  two-dimensional  tables  whereby  columns  represent  attributes,  and  each  row  has 
a  unique  key. 

The  next  major  step  in  designing  relations  is  to  apply  integrity  rules  involving  five  constraints; 
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•  Primary  key 

•  Foreign  key 

•  Uaique  key 

•  Check  function 

•  Null  value 

Majntajning  a  good  relation  and  constraint  integrity  is  helpful  to  avoiding  table  anomalies  in  the 
user  database  i^uery  such  as  insertion,  deletion,  and  modification.  Furthermore,  the  so-called 
normali2ation  process  must  ensure  functional  dependencies,  i.e .  one-way  relationship,  with  a 
determinant  and  another  attribute  dependent  on  it.  We  also  decompose  a  relation  into  a  group  of 
smaller  relations  m  accordance  with  die  principles  of  a  rationale  for  assigning  attributes  to 
entities  and  concepts  of  normal  forms. 

Of  course,  one  significant  goal  of  a  database  is  for  external  application  uses.  A  convenient 
query-response  capability  facilitating  such  applications  is  a  structural  query  language  called  SQL 
with  the  following  features; 

•  IIML  class  model 

•  Tables  and  data 

•  Database  and  table  stmetures  -  name,  keys,  indexes,  columns,  data  types,  null  values 

•  Entity  integrity 

•  Data  entry  and  data  management 

•  Queries  and  mathematical  operations 

We  went  through  a  number  of  UML  data  modeling  activities  based  on  each  area  of  RFID.  CLM, 
AEI,  and  EDI  sources.  The  models  contain  classes,  objects,  entities,  attributes,  relationships,  and 
eniiTy-reiaiionship  diagrams  (ERD).  The  ERD  is  used  to  map  out  the  logical  structure  image  ofa 
database.  The  major  role  here  is  to  describe  the  data  representation  and  object  nature  of 
relationships  among  entities  in  the  overall  database.  This  process  follows  a  development  life 
cycle  to  yield  an  entity-relationship  diagram  that  was  used  to  develop  the  physical  data  modeling 
presented  in  ihe  following  section. 

The  physical  data  modeling  process  is  used  to  convert  ihe  ERD  and  normalized  images  into  a 
physical  model.  A  few  objects  are  converted  into  equivalent  counterparts  in  the  physical  model; 

•  Entity  to  Table 

•  Attribute  10  Column 

•  Tuple  to  Row 

•  Association  to  Relationship  (Foreign  Key! 

•  Candidate  Key  to  Pnmary  Key  and  Index 

•  English  Object  Name  lo  Physical  database  name 

An  end  user  will  be  able  to  easily  join  several  tables  using  foreign  key  relationships  lo  query 
each  specific  transportaiion  conirol  number,  shipment,  container,  railcar,  shipping  document, 
shipping  date,  or  u^n  station  location.  The  EDI  data  loops  can  be  assigned  primary  key  columns 
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ii)  bijdd  feluiOD&hipa  bepih'eej]  ouier  levels  anJ  innee  kveli.  An  end  user  can  alio  select  data 
from  tables  beM'een  dtfTereni  iransacnon  seu  tables.  The  Final  database  DDL  sceipis  can  be 
referenced  by  a  requesL 


6.8  Dulubase  MaDigemcni  Tnnis 

The  SQL  Server  Enterprise  (Manager  is  a  graphical  interface  tool  as  shown  in  Figure  12  lo 
odninister  the  server  and  the  database  of  JoIntData  (by  ibis  project).  We  use  the  Enterprise 
Manager  to; 


•  Configure  SQL  Server  opuons. 

•  Register  databases, 

•  Create/edn/vKW  database  schema  and  data. 

•  Replicate  stand-by  databases, 

•  Perform  maintesance  and  backups,  and 

•  Monitor  perlbmiance. 
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Flyure  12.  SQL  Server  EoterprUe  Maonyer 

In  the  area  of  security,  a  backup  and  disaster  recovery  plan  is  created  to  provide  100%  data 
restore  protection.  This  backup  plan  is  shown  in  Table  12; 
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Table  IZ.  Backup  Plan 


Cvtle 

Path  and  BAR  File  Namrs 

G«  Mr*  Ikons 

Full  Djwkuf> 

mm 

b:  Backup_FullJointDjia^l  ^20070.30 101.3022  BAK 

12 

ffll 

b:  Backup_DiirJomlData_D^2m7().3()l  U)1512.BAK. 

14 

F  D k  u  p_Log  J  oiiii  D.ilj  ^  T  .  200  •  030 1  OkOO  1 5  BAK 

24 

Another  disaster  recover  plan  is  created  and  must  be  able  to  restore  all  damaged  transactions  all 
the  way  to  the  crash  time.  As  described  m  Table  1 3,  If  the  crash  time  is  at  10;30  am, 
Wednesday,  the  SQL  Server  Restore  tool  will  be  used  Three  types  of  files  must  be  set  into  the 
Restore  Plan:  ( I )  Sunday  full  backup  file,  (2)  Tuesday  night  ditrerenilal  backup  file,  and  <3) 
Wednesday  10  am  transaction  log  backup  tile  or  10:30  am  transaction  log  tile.  Theretbre,  the 
Restore  Plan  tool  will  be  able  to  restore  all  lost  data  to  the  crash  time  of  10:30  am  Wednesday 
using  timestamp  and  checkpoints. 

Table  13.  Disaster  Recovery  Plan 


Crash 

Time 

ts^^m 

Time 

Ceneraled 

Path  and  BAR  File  Names 

Database 
crashes  at 

10  30  am. 
Wednesday 

Full 

Backup 

1  am, 

Sunday 

E.  Backup_FullJoii)lDaia_F_2i)0703030)  3022.BAK 

Diffcneral 

Backup 

lOpm, 

Tuesday 

E;\Backup_D)n'JointDau_D_20070.306l0l  5 12  BAK 

10  am, 
Wednesday 

F:3Backup.  Log  Jni  niData_T_2i)(l703  0 1 OSOO 1 5  BAK 

Transaction 

Lok 

10  30  am, 
Wednesday 

C:'SQLScrser  DataJointData  log.LDF 

6.9  Evirtcilon,  Transformation,  Loading  Progrtios  <<>0  Programming) 

The  Extraction,  Transformation,  and  Loading  (ETL)  procedures  are  the  cniical  programs  (stored 
procedures.  Diggers,  and  CS  DLL)  we  wrote  to  process  collected  RPID,  CLM,  A£l,  and  EDI 
data  and  load  them  into  the  database  of  JomtDaia.  The  process  has  been  automated  from  the 
remote  scanner  sue  locaDons  to  the  JDDSP  database  without  human  being  intemipoon  as 
follows' 

I  At  remote  scanner  site,  a  record  is  logged  into  a  file  whenever  a  container  passes 

through  a  designated  lane  Every  IS  minutes,  a  Windows  scheduled  job  will  PUSH  this 
file  to  the  datacenter  via  an  internet  or  TELNET  transfer  protocol. 
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2  Ai  the  daiacenier  server,  a  path  and  folder  wit)  be  assigned  lo  each  site  lo  receive  all 
Gles  from  al)  remote  sites.  For  instance,  the  scanned  Hies  from  TCOS's  Sue 
’AlsCartageKtch'  wil)  besend  to  the  C:/TCOS/A)sCaitageKtch/Eveni  of  the  Database 
Server  (see  Figure  13). 

3  A  SQL  scheduled  job  will  be  kicked  off  every  one  minute  to  run  the  Auto  Data  Load 
program  wbicb  will  visit  each  folder  specified  from  Step  2,  read  one  file  at  a  time  until 
all  files  are  completed,  extract  records  and  transform  values,  assign  primary  keys  and 
foreign  keys,  and  load  ihem  mio  a  user-fnendly  relational  database.  The  Figure  14 
displays  on  example  of  this  database  table,  T COS_EveDlRpt_OSC3,  which  had  been 
loaded  with  TCOS  records. 


Figure  13.  Patb  and  Folder  to  Receive  TCOS's  Site  Files 
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Figure  14,  TCOS  DauUasc  Records 
6,10  Databisc  ^ppllcailoosaod  Malotonaocc 
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nie  will  be  reprocessed  and  gel  moved  to  C;TC'OS/ALsCartageKJch^Even(/Proce8sed. 
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7.0  METADATA 

The  creation  la&ks  of  the  Metadata  engine  and  repository  database  are  based  on  the  Object- 
Onenteil  DM  L  models  and  database  design  of  the  preceding  two  sections. 

7.1  Vfetodats  tre  Abstract 

The  simple  act  of  describing  real-world  phenomena  generates  absiraci  information  that  qualifies 
as  Metadata.  In  data  design,  real-world  phenomena  are  also  described  in  abstract  terms.  For 
example,  people  are  designated  as  employee  (Metadata).  In  sollware  design,  the  database 
structures  that  store  data  can  be  abstracted  into  Metadata  classification  schemes  that  make  sense 
to  developers  and  designers.  In  the  00  development,  a  table  (Metadata)  is  derived  from  an 
object,  which,  in  turn,  an  object  (Metadata)  can  be  derived  from  a  class. 

There  are  multiple  levels  of  abstraction  in  Metadata.  You  can  describe  a  data  instance,  then 
describe  that  description,  and  continue  to  describe  subsequent  descriptions  until  you  reach  some 
practical  limit  We  have  described  class,  object,  instance,  table,  column,  index,  primary  key, 
foreign  key,  and  five  constraints  in  die  preceding  sections,  we  will  continue  to  describe  the  next 
level  of  abstraction  as  another  Metadata  for  this  central  tracking  database 

7.2  Definitions  and  Background 

The  Metadata  are  data  used  to  descnbe  other  data  Metadata  describe  the  structure  and  meaning 
of  data,  as  well  as  the  structure  and  meaning  of  applications  and  processes.  It  is  important  to 
remember  that  Metadata  are  abstract,  have  a  context,  and  can  be  used  for  multiple  purposes  in 
the  further  development  of  systems. 

Within  the  DOD,  several  types  of  Metadata  can  be  found  including: 

1  Descriptive  Metadata  (table  names,  object  names,  etc.), 

2  Structural  Metadata  (primary  keys,  foreign  keys.  Indexes,  etc,), 

3  Semantic  Metadata  (program  documents,  XML  documents,  etc.),  and 

4  Usage  Metadata  (application  system  documents,  packages,  etc ) 

This  section  will  generate  all  four  Metadata.  As  well,  we  will  rely  on  SQL  Server  Metadata 
Services  in  order  to  standardize  retrieval  of  information  from  the  JoiniDaia  database  created 
from  the  preceding  sections 

7.3  M  eiodata  Have  M  ultiple  Purposes 

All  project  members  can  work  with  Metadata  information  just  as  one  would  with  any  kind  of 
data  design  elements.  Expressing  standard  design  information  as  Metadata  opens  up  new 
possibilities  for  reuse,  sharing,  and  multiple  loi^  support  For  example,  defining  data  objects  as 
Metadata  enables  project  members  to  see  how  they  are  constructed  and  versioned.  Versioning 
support  provides  a  way  to  view  and  retrieve  any  historical  version  of  a  particular  DTS  package  or 
table  layout  definitions.  When  we  develop  codes  based  on  Metadata,  we  can  define  a  structure 
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once  and  then  reuie  it  to  create  multiple  instances  that  can  be  vecsioned  tor  specific  tools  and 
applications 

In  summary,  the  major  purposes  of  Metadata  in  the  Integrated  Tracking  System  are  to: 

1  Categome  the  items  of  JDDSP  database  objects  into  groups. 

2  Enable  project  members  and  stakeholders  to  retrieve  data  based  on  categories  and 
versions 

3  Serves  as  a  clearinghouse  for  official  standards  and  documents  across  SM  21  projects. 

4  Identity  highly  rated  data  for  container  search 

5  Enable  the  JDDSP  database  to  interact  with  other  systems  such  as  simulations, 
wireless  devices,  marine  terminals,  and  supply  chains. 

6  Promote  data  visibility  and  reusability  for  the  future  SM  2 1  projects 

7.4  Designing  Mcitdata  L'slog  SQL  Server  Mela  Data  Services 

The  M  eta  Data  Services  of  SQL  Server  Enterprise  Manager  will  be  used  to  design  Metadata 
The  major  Metadata  architecture  consists  of  (IJ  Repository  Engine,  (2)  Metadata  repository 
database,  (3)  Information  Model,  and  (4)  Exporting  Metadata  to  XML  for  browse.  All  four 
components  will  be  described  as  follows. 

7.4.1  Repository  Engine 

The  repository  engine  Is  a  service  in  the  SQL  Server  Enterprise  Manager  (called  Meta  Data 
Services)  that  provides  basic  functions  for  storing  and  reuieving  objects  and  maintaining  the 
relationships  among  them  The  engine  performs  these  functions  within  the  content  of  an 
Information  Model  (see  Section  7.4.3)  The  engine  processes  user-defined  model  information  to 
determine  how  to  store  and  support  objects,  relationships,  and  actions.  When  you  click  the  Meta 
Data  Services,  the  repository  engine  will  manipulate  instances  and  elements  of  Information 
Models,  the  engine  does  so  only  to  the  extent  that  the  model  structure  allows.  Figure  16  shows 
the  Meta  Data  Services  (m  the  middle  caption  of  the  figure)  in  the  SQL  Server  Enterprise 
Manager. 

7.4J  Repository  Database 

SQL  Server  Meta  Data  Services  is  a  software  component  providing  not  only  a  repository  engine 
but  also  an  object-oriented  repository  database  that  stores  and  manages  metadata  for  SQL  Server 
and  its  components.  The  repository  database  is  a  storage  room  to  store  all  details  of  Metadata 
Again  Figure  16  shows  the  repository  database  with  the  caption  dbo  on  the  left-hand  side. 
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Figure  16.  Meto  Data  Services  -  Reposiforv  Eiiglue 


1.4.3  loformacioit  Mode!  of  UML 


DeployiDg  Microsoft  SQL  Server  Meia  Dau  Services  technology  beguis  with  this  [nformotion 
Model.  An  Informalion  Model  defines  Meiadaia  types  that  are  stored  id  a  repository  database 
and  used  by  tools  and  applications.  In  Secuoc  S,  we  developed  four  data  models  and  they  were 
used  to  create  the  Information  Model  ofJointData  database  m  Section  6.  Meta  Data  Sers'tces  is 
intended  to  be  used  tn  this  section  with  tntormaiton  inodebi  that  provide  type  is  formation  about 
the  Metadata. 


7.4.4  Meiadiia 

We  ran  Meta  Data  Services  to  impoti  metadata  from  the  JomtDoia  database.  This  process  took  a 
few  minutes  to  generate  all  descriptions  (Metadata)  from  the  JoiniData  ob;evts.  Figure  16  gives 
a  bsuog  of  Metadata  in  the  lowest  level  sianiDg  with  PK_214_LX_Trans^lLiDeNum  (a  primary 
key  for  the  2l4_LX_TninsSetLineNuin  table).  If  we  continue  to  expand  the  next  lower  level,  all 
underneath  coluitios  and  data  types  will  be  displayed.  These  are  all  pan  of  the  Metadata 
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7.43  E%  porliiig  M  etodaia 

Since  ihe  MeioUatQ  ii ^ung  » lurJ  to  read  on  ihe  Meta  Data  Services,  an  easy  wuy  is  to  expon  ihe 
Metadata  to  Excel  or  ^OdL,  then  we  can  sort  out  die  Metadata  (o  search  deaonpiions  and  ciass 
luunea.  Figure  17  displays  an  Excel  export  hsiing  after  sorting  and  Figure  18  displays  an  XML 
export  listing.  The  very  first  entry  is  PK_2I4_LX_TraftsSetLineNum  (which  is  a  prunary  key 
for  the  214_LX_TransSeiLineNiim  table)  in  both  expan  listings. 
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8.0  WE  BAND  XML  DEMONSTRATIONS 

8.1  Backgroiiod  and  Goals 

After  a  u&er-fnendly  relaiiona)  database  is  created,  we  need  a  front-end  screen  for  an  end-user  or 
a  stakeholder  to  read,  wnie,  update,  and  delete  die  data  and  reports.  An  XML  Web  system  is 
extremely  appropriate  m  this  application  m  terms  of  its  remote  accessibility  and  affo^bility. 

Tbe  purpose  for  applying  an  XML  Web  application  on  the  relational  database  system  Is: 

•  To  allow  a  stakeholder  to  use  a  remote  web  page  to  easily  interoperate  with  a 
database  and  make  decisions  on  a  near  real-time  basis. 

8.2  Cooflgurotloo  of  Internet  Informailoo  Services 

An  XML  Web  application  requires  writing  client-side  scripts  and  server-side  scripts.  The  client- 
side  scripts  can  Ik  executed  using  the  Internet  Explorer  a  Personal  Computer  The  server- 
side  scripts  must  be  executed  on  a  server.  So  we  need  an  Internet  Information  Server  { 1 1 SJ 
service  implemented  in  a  PC  workstation.  The  IIS  is  a  service  to  be  installed  in  a  Personal 
Computer  Windows.  This  IIS  will  be  functioning  as  a  group  of  Internet  servers  (including  a 
Web  or  Hypertext  Transfer  Protocol  server  and  a  File  Transfer  Protocol  server)  with  similar 
capabilities  to  Windows  Server  operating  systems.  Therefore,  the  IIS  allows  us  to  create  and  test 
the  server-side  scripts  of  an  XML  Web  application  in  a  Personal  Computer  without  using  a  real 
Windows  2003  server.  In  the  XML  development,  we  must  also  use  Windows  provided  folder 
structure  which  resides  at  C:Uneipub^ointDaia\  and  C '^Jnetpub^wwwroot  to  conduct  testing. 
After  the  XML  Web  application  is  completed,  all  programs  will  be  moved  to  a  real  Windows 
web  server  to  be  published.  The  SQL  Server  provides  a  tool  to  configure  an  IIS  Virtual 
Directory  as  shown  in  Figure  19 
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Table  l4oiii]inea  the  required  procedures  and  respcciive  specificaiioiu  forihe  IIS  conHyurauun. 


Teirte  14.  Procedures  and  SpcdflcaUans  far  (IS  Coanyurodoo 


Procedures 

Specincatloas 

(kneral  IIS  Name 

luiikiDaui 

Lixal  Path 

C'  itii'inub  JviniDju 

Loeon 

SQL  Server  Database 

SM02  JoifiiDaia 

Sciuni's 

Allow  CRL.  Tcmnldic.  XPjth.  Pusi 

Vjriiia)  Name 

Teitinijio 

8J  Coding  of  XML.  XSL,  and  .Stored  Procedures 

The  SQL  Server  daiabase  is  an  XML-enabled  DBMS,  Mliich  can  read  and  write  XML  data, 
remro  data  from  databases  in  XML  format,  and  read  and  update  data  stored  m  XML  documeois 
The  XML  documents  can  be  embedded  m  a  Web  Portal  and  SQL  Server  has  a  number  of 
UifTetent  ways  to  support  XML 
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Our  XML  l0i;ic  sta/ii  with  a  requeai  from  a  uaer.  Thia  request  executes  a  stored  procedure  which 
will  query  the  ddtabdse  using  SQL.  Then  the  database  retimu  a  nimiber  of  record  and  generates 
a  XML/Tag  ducumcnf  listing  to  embed  the  records.  This  XML  document  needs  an  XSL  style 
sheet  to  format  and  demonstrate  the  rc-suks  on  an  XML  web  page.  Figure  20  describes  this  logic. 
The  examples  of  stored  procedure,  SQL  query,  XMLTag  codes,  and  XSL  can  also  referenced  by 
a  request 


Figure  20.  Logic  of  XML  Rcquosi/Dciuo  Procedure 
8.4  Web  Demoastrailons 

The  XML  Web  appUcation  resided  id  one  section  of  the  SM  2 1  Web  Portal  m  the  SharePomi 
intecnet  area.  The  XML  scTipts,  database  programs,  and  pictures  are  hosted  in 
C:'Jiieipub\JoiBlDara\  m  the  SM02  server  as  ibown  in  Figure  21 . 
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Flisurt  2 1.  AJ{  XML  Web  rrograiiu  aod  Plciurea  lo  C:\loc<pub 


U wr%  can  v  uii  ilieg«  XML  web  poges  by:  ( 1 )  Coiuieciiag  to  VPN  ( 66. )  62  J  S. )  0)  and  (2) 
Entering  hnp'  ■SMQl.'Beaional  Planning  DofJiJliJWx  tn  the  Addreia  bne  of  an  Iniemei  Explom 
Then  the  Home  page  of  ihe  SharePoint  Web  Po<u)  wtll  be  dj  splayed.  The  u^r  cim  conilnue  lo 
click  the  Icon  (JoiniDau)  under  Site  Hierarchy  lo  hyperlink  lo  the  Main  Menu  of  the  JuiniDdta 
database  as  «d^ovpn  in  Figure  22. 


Dev0bpfl3Ml  of  Joifii  Dota  Siandords  and  Commimication  Protocols 


TCCSSte  SiabM; 

CPdcHgg 

TCOSEw^tSttHua: 

cuLtsca 

CiidthOT 

60t  rf— wv  Shlp«mnt»! 

if  


Car  Lpottio  Haasaqebi 

fllrUM— 

MtocqujpmMtldantnuD^j 

Ctrkh^ 

QKkHfn 

EDIRaHShlumflnb: 

I  ±1^ 


Figure  22.  Mila  Menu  ofJoloiData  Databiu* 

The  Main  Menu  ouilines  a  number  of  caieyories  which  allow  a  user  to  click  and  select  a  specific 
XML  document  listing  The  categones  collecting  numerous  exainple  records  from  difTereoi 
sysiems  are  shown  in  Table  15. 

After  die  user  clicks  and  selects  one  of  the  categories,  a  quest  will  query  the  requuied  records 
Iroin  the  relational  database,  generate  a  XML  document  listing,  match  a  style  sheet  for  the 
display  formal,  and  then  populate  the  results  on  a  web  page.  Figure  23  shows  on  }ML 
Document  page  on  TCOS  event  status  and  a  Rail  Coosisi  is  shown  m  Figure  24. 
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Table  15.  Cati^orlcs,  S>&lemi.  Record  Forma  is  ofMaio  Meau 


CateMTlaa 

SvateiM 

Record  Format 

Radio  Frequeocy 

IdeniificaiiODS 

Trade  Comdor  Operahoe 

System  (Seaitle,  Toeotna, 
Alepi^de  CottiAwl 

1  Siiea 

2  Events 

3  Loetfi 

Car  LocatlcA  Mesoage 

MiLtary  Surface  Deployraeni 
and  DisiribuiiM  Commood 

1  SDDC  Henda 

2  SDDC  Details 

Auto  Equipmem 

IdeniificaiiODS 

TQ4  -  Common  Date  Formal 

1  T94  Heads 

2  T94  Details 

□ectroftic  Data  lfiiercbafi|e 

Ocean  bookioi.  vtaoel 

mtmtfeai,  BiU  of  Lading, 
Tertmoal  Operaitoo  Acuviiy. 
Load  Tender.  Transponauon 
Status,  Rai)  Waybill,  Rail 
Consist 

1  EDI  204.214 

2  EDI  301.304.309. 

322. 324 

3  EDI4M.4I7.4IR 

4  EOIB56.B5B 

Jdiai  Data 

louu  Data  tfo  various 
databases 

1  EDI  and  RFID 

2  EDI  and  CLM 

3  EDI  and  AEI 
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Figure  13.  XML  DucuiucDt  Page  fora  TCOS  Event  Status 
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9.0  CONCLUSIONS 
9.1  Suiontry 

TSe  propo&ed  Joint  Data  Standards  and  Communication  Protocols  are  vital  for  achieving 
etlictency  for  the  Integrated  Tracking  System  and  to  enhance  the  global  supply  chain.  We  hove 
rthown  that  the  network  secunty,  database  integration,  and  web  demonstration  are  facilitated  by 
using  standard  information  Hows  as  surrogates  to  characterize  movement  and  interactions. 

The  overall  objective  of  the  Integrated  Tracking  System  is  to  provide  the  JDDSP  Multimodal 
Terminal  Operating  Systems  the  rei^uired  data  for  tracking  containers  (empty  and  full),  chassis, 
rail  cars,  and  trailers  Tracking  can  be  enabled  by  the  EDI  or  wireless  identification  equipment, 
which  IS  descnbed  as  one  combination  of  the  following'  optica)  character  readers,  active  and 
passive  radio  frequency  idenuHcaiion  tags  and  readers,  differential  (IPS,  and  CVISN. 

This  project  involves  the  development  of  an  overall  Information  Technology  conceptual  design 
based  upon: 

•  Data  layer  collection  (RFID,  EDI,  etc), 

•  Relational  database  design  (Central  Database), 

•  XM  L  Web  demonstration  (Web  Portal),  and 

•  Datacenter  management. 

The  Integration  Tracking  System  is  supported  by  the  Joint  Data  Standards  and  Communication 
Protocols  for: 

•  Automated  ETL  data  transfer  (no  manual  intervention)  and 

•  Instant  query  using  XML  m  a  net  centric  environment. 

The  ITS  supported  by  the  Joint  Data  Standards  and  Communication  Protocols  can  support  the 
improvement  of  military  surge  force  deployments,  military  sustainment  shipments,  and 
commercial  shipments.  The  JDDSP  database  will  provide  the  tracking  data  necessary  for 
operating  the  JDDSP  multimodal  terminal  operating  system  and  will  able  exception  management 
of  shipments  into  and  out  of  the  facility. 

9J  Future  Research 

Additional  research  on  ihe  integrating  RFID  tag  messages  and  EDI/AE)  databa.«es  to  populate  a 
comprehensive  listing  of  all  container  contents,  bill  of  lading,  and  shipping  details  can 
significantly  benefit  the  industry.  Theretbre,  further  research  to  extend  completed  work 
includes' 


•  (liven  a  container  number  or  military  equipment  identificaiion,  how  can  this  shipment 
position  be  located  and  displayed  on  a  geographic  information  system  map? 
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•  Given  a  shipping  desiinaiion  for  a  container  number  or  military  equipment 
ideniiticauorw  how  can  a  shipping  destination  change  be  directed  from  a  routing 
instruciMan? 

•  Given  rapid  volume  growth  rate,  how  can  the  integration  database  system  be 
convened  to  a  data  warehousing  system? 

As  conceived  and  executed,  this  project  is  intended  to  enhance  goods  movement  by  providing  an 
integrated  means  for  desen  bing  the  dynamics  of  shi  pment  tracking  modeling  for  public  and 
private  stakeholders  and  to  conduct  data  collection  by  standardi2mg  the  transforming  process. 
The  JDDSP  Database  provides  a  means  of  obtaining  answers  to  “What  if’”  questions  The 
database  is  intended  to  answer  questions  such  as  those  associated  with  the  impact  of  increasing 
shipment  volume  on  throughput  capacity,  the  impact  of  changes  in  marine  terminal  loading 
processes,  and  alternative  future  infrastructure  capacity  (e.g.,  Victorville  inland  cargo  operation 
and  freeway,  railway  movement  visibility). 
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LIST  OF  ABBREVIATIONS 

AAR 

Association  of  Atnencan  Railroads 

AD 

Active  Directory 

A£l 

Automated  Equipment  Identifbcation 

AJ 

Artificial  Intelligence 

ANSI 

American  National  Standards  Institute 

APL 

American  President  Lines 

APS 

Agile  Port  System 

ASC 

American  Standards  Committee 

ASP 

Active  Server  Pages 

AVI 

AutomatM:  Vehicle  Identification 

BNSF 

Burlington  Northern  Santa  Fe 

CBL 

Commercial  Bill  of  Lading 

CLM 

Car  Location  Messages 

CSULB 

California  State  University,  Long  Beach 

CVISN 

Commercial  Vehicle  Information  System  and  Networks 

DB 

Database 

DBA 

Database  Administrator 

DBMS 

Database  Management  System 

DHCP 

Dynamic  Host  Configuration  Protocol 

DNS 

Domain  Name  System 

DPO 

Distribution  Process  Owner 

DSS 

Decision  Support  System 

DS7U 

Draft  Standards  for  Trial  Use 

EDI 

Electronic  Data  Interchange 

EMT 

Eflicient  Marine  Terminal 

ERD 

Eniity-relationship  Diagram 

ES 

Expert  System 

FTL 

Exu^tion,  Transformation,  Loading 

FAST 

Free  and  Secure  Trade 

FK 

Foreign  Key 

FTP 

File  Transfer  Protocol 

QBL 

Government  Bill  of  Lading 

CIS 

Geographic  Information  System 

GUI 

Graphical  User  Interface 

ICTF 

Intermodal  Rail  Transfer  Facility 

ID 

Ideniification 

IIS 

Internet  Information  Services 

IMS 

Information  Management  System 

IP 

Internet  Protocol 

ISP 

Internet  Service  Provider 

IT 

In  formation  T echnology 

ITS 

Integrated  Tracking  System 

JFCOM 

Joint  Forces  Command 

LA/LB 

Los  Angelea/Long  Beach 
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LAN 

Local  Area  Network 

NF 

Normal  Form 

NWITC 

Nonhweai  Iniemaiional  Trade  Corridor 

OCD 

Operottonol  Concept  Document 

ODBC 

Open  Daiabaie  Connectivity 

PC 

Personal  Computer 

PK 

Pnmary  Key 

POD 

Pomi  of  Debarkation 

POE 

Port  of  Embarkation 

PPGBL 

Personal  Property  C>ovemment  Bill  of  Loding 

RFID 

Radio  Frequency  Identification 

RSCS 

Regional  Supply  Ctvain  Simulation 

SCLA 

Southern  California  Logistics  Authority 

SDDC 

Surface  Deployment  and  Distribution  Commands 

SM 

Strategic  Mobility 

SQL 

Structured  Query  Language 

sw 

Software 

TCMD 

Transportation  Control  and  Movement  Document 

TCOS 

Trade  Corridor  Operating  System 

TCP 

Transmission  Control  Protocol 

TPL 

Third-party  Logistics 

OML 

Unified  Modeling  Language 

OMLER 

Universal  Machine  Language  Equipment  Register 

OP 

Union  Pacilic 

ORL 

Uniform  Resource  Locator 

OSTR  AN  SCOM  OS  T  rajisforuiion  Command 

VPN 

Virtual  Private  Networks 

WAN 

Wide  Area  Networks 

WSDOT 

Washington  Stale  Department  of  Transportation 
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